After applying the patch.

We continue to request MISSION_ITEM so as not to break older ground control stations.

I deal with one which this PR would adversely affect (I'm nudging the author to update....).

Which GCSs have you tested with these changes?

I deal with one which this PR would adversely affect (I'm nudging the author to update....).

Please add a link there that marks this PR as duplicate, so it is to be closed along with it.

Which GCSs have you tested with these changes?

I'm hunting some Mavlink issues with QGroundControl and ELRS 900M, very frustrating topic because ELRS 2G4 works perfectly and mLRS 900M also works perfectly.

EDIT:
These also work with the change.

• APM-Planner_2-2.0.30-rc3
• MissionPlanner1.3.82

Tested again after a git hard reset onto the change, and the internal error is gone. It was likely the check in line 371 being reverted on stashed changes.

Requires ArduPilot/MAVProxy#1492

I deal with one which this PR would adversely affect (I'm nudging the author to update....).

Please add a link there that marks this PR as duplicate, so it is to be closed along with it.

That particular GCS is not open-source.

Which GCSs have you tested with these changes?

I'm hunting some Mavlink issues with QGroundControl and ELRS 900M, very frustrating topic because ELRS 2G4 works perfectly and mLRS 900M also works perfectly.

EDIT: These also work with the change.

* [APM-Planner_2-2.0.30-rc3](https://github.com/ArduPilot/apm_planner/releases/tag/2.0.30-rc3)

* [MissionPlanner1.3.82](https://github.com/ArduPilot/MissionPlanner/releases/tag/MissionPlanner1.3.82)

Nice! I've fixed MAVProxy to work with it.

We'll need to follow a process here so as to give people plenty of warning that things are going to break. It is well past time that we did follow some process to get this done.

There are many GCSs and tools out there that would be adversely affected by this patch if we were to simply merge it. MAVProxy users are likely to update relatively frequently - but uGCS users perhaps not.

We may need to carry an options bit for a while to allow a user to get the old behaviour back.

I am curious to know what real-world problem you are trying to solve with this patch. I assume there's a client which only handles MISSION_REQUEST_INT, and can't be modified to also handle MISSION_REQUESTs from the autopilot?

We'll need to follow a process here so as to give people plenty of warning that things are going to break. It is well past time that we did follow some process to get this done.

It would be the professional way to introduce breaking changes with a new major version.
A deprecation warning in the release notes from 4.6 onward is a fair warning of an error that will hit with 5.0 .

I am curious to know what real-world problem you are trying to solve with this patch. I assume there's a client which only handles MISSION_REQUEST_INT, and can't be modified to also handle MISSION_REQUESTs from the autopilot?

None, just a side finding. A decade or two on the job, does teach to address technical debt immediately.

We'll need to follow a process here so as to give people plenty of warning that things are going to break. It is well past time that we did follow some process to get this done.

It would be the professional way to introduce breaking changes with a new major version. A deprecation warning in the release notes from 4.6 onward is a fair warning of an error that will hit with 5.0 .

We don't tend to use the major-version-breaks-things semantics suggested by a lot of people.

Instead code tends to get made optionally-compilable. We send a warning message for a while (yes, the timekeeping on this is that exact...), then we compile the code out by default, then we remove the code. All in "approximate time". I've started to leave comments around this code indicating when things should happen, but typically these steps occur on minor version changes - which are supposed to be every 6 months or so.

I am curious to know what real-world problem you are trying to solve with this patch. I assume there's a client which only handles MISSION_REQUEST_INT, and can't be modified to also handle MISSION_REQUESTs from the autopilot?

None, just a side finding. A decade or two on the job, does teach to address technical debt immediately.

OK, so no immediate concern here. Expiring technical debt is rather easier when you control all of the moving parts :-)

I'll put a message out on the ardupilot-gcs mailing list to try to prompt people to ensure they support MISSION_ITEM_INT requests from the autopilot.

https://github.com/ardupilot/ardupilot/blob/master/libraries/GCS_MAVLink/GCS_config.h#L107 shows where we are warning on the other side - so if a GCS is requesting items using MISSION_REQUEST rather than MISSION_REQUEST_INT` they get a one-time warning.

I think we will probably need to do some form of probing for support here. So request an item using MISSION_REQUEST_INT and if no response is received fall back to MISSION_REQUEST - and bitch at the user.

That's probably stashing away the currently-sending-type (MISSION_REQUEST or MISSION_REQUEST_INT), and a pointer to the relevant method (mavlink_msg_mission_request_send) or mavlink_msg_mission_request_int_send). A small patch in MissionItemProtocol::updates timeout handling code can switch to the non-INT version and warn the user. MAVProxy can be used for testing by reverting that PR I merged against it.

Did you want to do that work (or something better!), or shall I?

Did you want to do that work (or something better!), or shall I?

I will add once I'm done with the 900M ELRS Mavlink Issue.
This will eventually hit MissionPlanner as well.

Well, tested, works but produces false positive warnings on high latency links.

I'm against this workaround and support old stuff forever approach.

I prefer the clean cut method. Drop support at next major version.

There is also an issue with the advertised capabilities and the mavlink fork of ardupilot not being up to date.

-2